One Platform, the Whole BFSI Stack

Section 01The Six‑Vendor Problem

Walk into the collections floor of any mid-sized Indian NBFC or bank and you will find a remarkably consistent technology stack. A cloud telephony provider handles outbound calling. A separate CRM tracks borrower records and interaction history. A third tool manages SMS and WhatsApp campaigns. A fourth handles field agent routing via Google Maps. A fifth provides analytics and reporting. And a sixth - often a spreadsheet - tracks compliance.

Each of these tools was selected independently, often by different teams, at different points in the organization's growth. Each has its own data model, its own authentication, its own API surface, and its own vendor relationship. The result is an architecture that is technically functional but operationally fragmented: data moves between systems through manual exports, CSV uploads, and webhook configurations that break when any single vendor updates their API.

Sources: IBEF, India BFSI Sector, 2025; CEIC Data, India NPA Ratio, 2025

The consequences of this fragmentation cascade through every operational metric. When the dialer does not share data with the CRM in real time, an agent might call a borrower who already made a payment that morning. When the route planner does not know about the AI-analyzed call transcript that flagged a borrower as cooperative, the field agent arrives without context. When compliance monitoring lives in a separate system from the interaction platform, violations are discovered days or weeks after they occur rather than prevented in the moment.

The fundamental question is not which tools are best. It is whether the collections stack should be a stack at all - or whether the operational, analytical, and governance functions of collections belong on a single platform, sharing a single data model, governed by a single protocol.

Section 02The Full‑Lifecycle Collections Platform

An integrated collections platform replaces the multi-vendor stack with a unified architecture that handles every stage of the collections lifecycle: from the moment a borrower portfolio is uploaded, through risk classification and channel allocation, across every outbound interaction (voice, SMS, WhatsApp, email, field visit), through AI-powered analysis and quality scoring, to legal action management and final resolution.

The diagram above is not aspirational. Each layer corresponds to a production component. The key architectural principle is that every layer shares a single data model. When a borrower is uploaded in the Ingest layer, classified in the Classification layer, allocated in the Allocation layer, and contacted through the Orchestration layer, every system component sees the same borrower record, the same interaction history, and the same compliance state. There is no ETL between systems, no CSV export from one tool and import into another, and no reconciliation between conflicting data sources.

Section 03Layer by Layer: What Consolidation Actually Delivers

Ingest: Portfolio Upload and Schema Mapping

The first thing a collections operation does is receive borrower data. In most organizations, this arrives as a CSV export from the core banking system or loan origination system. The platform ingests this data, validates it against a defined schema (borrower ID, name, phone, loan amount, overdue amount, days overdue), and flags missing or malformed records before processing begins. For organizations with API-connected core banking systems, the same data flows automatically through a real-time sync.

The schema mapping capability is critical for multi-tenant deployments. Different lenders use different field names, different data formats, and different structures for the same underlying information. An AI-powered schema mapper detects these variations and aligns them to the platform's canonical data model automatically - reducing the integration timeline from weeks to hours.

Classify: AI-Powered Risk Tiering

Once borrower data is ingested, the platform classifies each account into risk tiers. The standard five-tier model segments borrowers by a combination of days past due, outstanding amount, payment history, and behavioral signals (if available from prior interactions). This is not a static bucketing exercise. The classification model incorporates predictive analytics: which borrowers are likely to self-cure, which will respond to a digital nudge, which require a voice call, and which are headed toward legal action.

The classification output directly feeds the allocation engine. A Tier 1 borrower (early delinquency, likely to self-cure) might receive only an automated SMS reminder. A Tier 3 borrower (moderate delinquency, declining responsiveness) might be allocated to the AI voice agent for a multilingual collection call. A Tier 5 borrower (severe delinquency, no prior engagement) might be flagged for field visit or legal escalation. This tiering-to-channel mapping replaces the manual allocation decisions that in most organizations consume hours of management time daily.

Orchestrate: Omnichannel Execution

The orchestration engine executes the collection strategy across all channels simultaneously, governed by the AGP compliance layer. This is where the single-platform architecture delivers its most significant advantage over the multi-vendor stack: the ability to coordinate across channels in real time.

Consider a scenario: the AI voice agent calls a borrower and identifies a promise-to-pay. The platform immediately cancels the scheduled SMS reminder (which would now be redundant and potentially annoying), updates the field visit priority (downgrading the borrower from the next day's route), triggers a WhatsApp payment link at the agreed time, and schedules a follow-up call if payment is not received within the committed window. In a multi-vendor stack, each of these actions would require separate API calls, webhook triggers, and manual coordination. On a unified platform, they are orchestrated by the same engine that processed the call.

Analyze: AI-Powered Call Intelligence

Every voice interaction passes through an AI quality analysis pipeline that extracts structured intelligence from unstructured conversation. The pipeline transcribes the call using speech-to-text, analyzes the transcript for key topics (objections, promises, hardship claims), detects sentiment across the conversation arc, evaluates the agent's performance against quality parameters (greeting, empathy, clarity, resolution), generates a quality score on a 0-100 scale, and recommends the optimal next action.

This analysis is not a post-hoc reporting exercise. It feeds back into the orchestration engine in near-real-time. If the AI detects that a borrower expressed genuine financial hardship during a call, the system can automatically flag the account for a restructuring review rather than scheduling another aggressive follow-up. If the borrower indicated they prefer to be contacted in the evening, the system adjusts future scheduling accordingly.

Field Operations: Route Optimization and Deviation Analysis

For borrowers who require in-person visits, the platform provides route optimization using geographic data, visit prioritization based on AI-analyzed call intelligence, and real-time deviation analysis that compares planned versus actual routes. The field agent accesses borrower context - including transcripts from prior calls, payment history, and the AI-recommended approach - through a mobile application that works across 22+ Indian languages.

Deviation analysis is particularly valuable for compliance and operational efficiency. When a field agent deviates significantly from the planned route, the system flags the deviation for review, enabling managers to identify whether the deviation was justified (e.g., a borrower was not at the expected address) or indicates an operational problem (e.g., an agent is skipping difficult visits). This GPS-based accountability operates at a level of granularity that paper-based field management cannot approach.

Legal Management: End-to-End Recovery Tracking

For accounts that escalate beyond collection into recovery and legal action, the platform tracks cases across multiple legal frameworks: Section 138 of the Negotiable Instruments Act (bounced check proceedings), arbitration, and SARFAESI (Securitisation and Reconstruction of Financial Assets) proceedings. Each case is tracked by stage, hearing date, and outcome, with automated reminders for upcoming hearings and deadlines.

This legal layer closes the final gap in the collections lifecycle. Without it, legal recovery exists in a separate system (often a law firm's case management tool or another spreadsheet), disconnected from the collections interaction history that preceded it. On a unified platform, a legal team reviewing a case can see every call transcript, every SMS, every field visit note, and every AI-analyzed quality score from the pre-legal collections phase - providing context that materially improves legal outcomes.

Section 04The Multi‑Tenant Dimension

For lenders, NBFCs, and system integrators managing collections across multiple client portfolios, the platform architecture supports full multi-tenant isolation. Each tenant operates in an isolated environment with its own data, configurations, users, governance rules, and LLM settings - while sharing the underlying platform infrastructure.

The three-plane model separates platform governance (Adya AI) from client customization (partners and system integrators) and daily operations (enterprise clients). This separation is not just organizational - it is architectural. Tenant isolation is enforced at the database level with tenant-scoped queries, at the application level with JWT-based access control, and at the API gateway level with cross-tenant request blocking. A vulnerability or misconfiguration in one tenant's environment cannot affect another.

For system integrators - particularly GSIs operating across multiple banking clients - this architecture enables a repeatable deployment model. The same platform is customized per client through configuration, not custom development. A new client deployment involves provisioning a tenant, mapping the client's database schema, uploading governance documents (SOPs, SLAs), and configuring channel integrations. The platform's AI-powered schema mapping and governance-to-rules conversion mean this onboarding can be completed in days rather than months.

Section 05What Consolidation Replaces

The consolidation is not just about reducing vendor count. It is about eliminating the integration tax - the ongoing engineering effort required to keep six systems synchronized, the data quality issues that arise when records are duplicated across systems, and the compliance gaps that appear in the seams between tools.

Section 06The API Layer: When You Do Not Want to Replace Everything

Not every organization will replace its entire stack overnight. For institutions with significant investment in existing systems, the platform provides a comprehensive API layer (RESTful, paginated, rate-limited) that enables selective integration. Batch data, borrower records, call analytics, allocation decisions, route plans, and performance metrics are all available through documented endpoints with API key authentication, permission-scoped access, and webhook support for real-time event notification.

This means a lender can start by replacing only the most broken component of their existing stack - typically the compliance layer or the voice channel - while maintaining their existing CRM and analytics tools through API integration. Over time, as the value of the unified data model becomes evident, additional functions can be consolidated at the organization's own pace.

Section 07What This Means for Your Next RFP

If you are evaluating collections technology for a bank, NBFC, MFI, or fintech in India or any BFSI market, the decision framework has changed. The question is no longer "which dialer should we use?" or "which CRM integrates best with our telephony?" The question is whether to continue investing in a multi-vendor architecture that creates integration overhead, compliance gaps, and data fragmentation - or to move to a platform architecture that treats collections as a single, governed, AI-powered system.

India's BFSI sector reached $1 trillion in market capitalization by growing credit at a 22% CAGR over two decades. That growth is accelerating into Tier 2 and Tier 3 markets, into linguistically diverse borrower segments, and into regulatory environments that are becoming simultaneously more complex and more technology-aware. The collections infrastructure that served the last decade - manual processes, fragmented tools, Hindi-and-English-only outreach - will not serve the next one.

The infrastructure exists. The question is whether to build on it now - or continue paying the integration tax while the market moves underneath you.